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The scrypt Password-Based Key Derivation Function 
Abstract 


This document specifies the password-based key derivation function 


scrypt. The function derives one or more secret keys from a secret 
string. It is based on memory-hard functions, which offer added 
protection against attacks using custom hardware. The document also 


provides an ASN.1 schema. 
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CRORES S) 


Password-based key derivation functions are used in cryptography and 
security protocols for deriving one or more secret keys from a secret 


value. 


Crypt-fu 
Standard 


GNU SHA-256/512 crypt 
ash, and the Blowfish-based bcrypt 


[NTLM] h 


Over the years, 
functions have been used, 
FreeBSD MD5 crypt, 


nction, 


s#5 (PKCS#5) 


several password-based key derivation 
including the original DES-based UNIX 
Public-Key Cryptography 


PBKDF2 [RFC2898] (typically used with SHA-1), 


[SHA2CRYPT], Windows NT LAN Manager 
[BCRYPT]. 


(NTLM) 


These 


algorithms are all based on a cryptographic primitive combined with 


salting and/or iteration. 


the comp 


utation, 


costlier. 


The iteration count is used to slow down 


and the salt is used to make pre-computation 


All password-based key derivation functions mentioned above share the 


same weakness against powerful attackers. 


Provided that the number 


of iterations used is increased as computer systems get faster, this 
allows legitimate users to spend a constant amount of time on key 


derivation without losing ground to attackers’ 


ever-increasing 


computing power -- as long as attackers are limited to the same 
software implementations as legitimate users. 
hardware implementations may not change the number of operations 


performed compared to software implementations, 
them from dramatically changing the asymptotic cost, 
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While parallelized 


this does not prevent 
since in many 
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contexts -- including the embarrassingly parallel task of performing 
a brute-force search for a passphrase -- dollar-seconds are the most 
appropriate units for measuring the cost of a computation. As 
semiconductor technology develops, circuits do not merely become 
faster; they also become smaller, allowing for a larger amount of 
parallelism at the same cost. 


Consequently, with existing key derivation algorithms, even when the 
iteration count is increased so that the time taken to verify a 
password remains constant, the cost of finding a password by using a 
brute-force attack implemented in hardware drops each year. 


The scrypt function aims to reduce the advantage that attackers can 
gain by using custom-designed parallel circuits for breaking 
password-based key derivation functions. 


This document does not introduce scrypt for the first time. The 
original scrypt paper [SCRYPT] was published as a peer-reviewed 
scientific paper and contains further background and discussions. 


The purpose of this document is to serve as a stable reference for 
documents making use of scrypt. The rest of this document is divided 
into sections that each describe parameter choices and algorithm 
steps needed for the final "scrypt" algorithm. 


2. scrypt Parameters 
The scrypt function takes several parameters. The passphrase P is 
typically a human-chosen password. The salt is normally uniquely and 
randomly generated [RFC4086]. The parameter r ("blockSize") 
specifies the block size. The CPU/Memory cost parameter N 
("CostParameter") must be larger than 1, a power of 2, and less than 
2°(128 * r / 8). The parallelization parameter p 
("parallelizationParameter") is a positive integer less than or equal 
to ((2%32-1) * 32) / (128 * r). The intended output length dkLen is 
the length in octets of the key to be derived ("keyLength"); it isa 
positive integer less than or equal to (2%32 - 1) * 32. 


Users of scrypt can tune the parameters N, r, and p according to the 
amount of memory and computing power available, the latency-bandwidth 
product of the memory subsystem, and the amount of parallelism 
desired. At the current time, r=8 and p=1 appears to yield good 
results, but as memory latency and CPU parallelism increase, it is 
likely that the optimum values for both r and p will increase. Note 
also that since the computations of SMix are independent, a large 
value of p can be used to increase the computational cost of scrypt 
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without increasing the memory usage; so we can expect scrypt to 
remain useful even if the growth rates of CPU power and memory 
capacity diverge. 


3. The Salsa20/8 Core Function 


Salsa20/8 Core is a round-reduced variant of the Salsa20 Core. It is 
a hash function from 64-octet strings to 64-octet strings. Note that 
Salsa20/8 Core is not a cryptographic hash function since it is not 
collision resistant. See Section 8 of [SALSA20SPEC] for its 
specification and [SALSA20CORE] for more information. The algorithm 
description, in C language, is included below as a stable reference, 
without endianness conversion and alignment. 


#define R(a,b) (((a) << (b)) | ((a) >> (32 - (b)))) 
void salsa20_word_specification(uint32 out[16],uint32 in[16]) 


{ 


int i; 

uint32 x[16]; 

for (i = O;i < 16;++i) x[i] = in[il]; 

for (i = 8;i > O;i -= 2) { 
x[ 4] ^= R(x[ 0]+x[12], 7); x[ 8] ^= R(x[ 4]+x[ 0], 9); 
x[12] ^= R(x[ 8]+x[ 4],13); x[ 0] ^= R(x[12]+x[ 8],18); 
xi 9] ^= R(x[ 5]+x[ 1], 7); x[13] ^= R(x[ 9]+x[ 5], 9); 
x[ 1] ^= R(x[13]+x[ 9],13); x[ 5] ^= R(x[ 1]+x[13],18); 
x[14] ^= R(x[10]+x[ 6], 7); x[ 2] ^= R(x[14]+x[10], 9); 
x[ 6] ^= R(x[ 2]+x[14],13); x[10] ^= R(x[ 6]+x[ 2],18); 
x[ 3] ^= R(x[15]+x[11], 7); x[ 7] ^= R(x[ 3]+x[15], 9); 
x[11] ^= R(x[ 7]+x[ 3],13); x[15] ^= R(x[11]+x[ 7],18); 
x[ 1] ^= R(x[ O]+x[ 3], 7); x[ 2] ^= R(x[ 1]+x[ 0], 9); 
x[ 3] ^= R(x[ 2]+x[ 1],13); x[ 0] ^= R(x[ 3]+x[ 2],18); 
x[ 6] ^= R(x[ 5]+x[ 4], 7); x[ 7] ^= R(x[ 6]+x[ 5], 9); 
x[ 4] ^= R(x[ 7]+x[ 6],13); x[ 5] ^= R(x[ 4]+x[ 7],18); 
x[11] ^= R(x[10]+x[ 9], 7); x[ 8] ^= R(x[11]+x[10], 9); 
x[ 9] ^= R(x[ 8]+x[11],13); x[10] ^= R(x[ 9]+x[ 8],18); 
x[12] ^= R(x[15]+x[14], 7); x[13] ^= R(x[12]+x[15], 9); 
x[14] ^= R(x[13]+x[12],13); x[15] ^= R(x[14]+x[13],18); 

} 

for (i = O;i < 16;++i) out[i] = x[i] + in[i]; 
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The scryptBlockMix algorithm is the same as the BlockMix algorithm 
described in [SCRYPT] but with Salsa20/8 Core used as the hash 


function H. 


Below, Salsa(T) 


function applied to the octet vector T. 


Algorithm scryptBlockMix 


Parameters: 
r 


Input: 
B[0] 


Output: 
B’ [0 


1. X = B[2 


N 
Hh 
O 
5 
H 


= 
ll 


X = Sa 
Y[i] = 
end for 


3. B’ = (YI 
Yl 


Block size parameter. 


|| BI1] 


|| ... || Bl2 * r- 1] 
Input octet string 
treated as 2 * r 64-octet blocks, 


corresponds to the Salsa20/8 Core 


(of size 128 * r octets), 


where each element in B is a 64-octet block. 


1 || Beg 


Output octet string. 


Pid BL 


‘CH elo Fae aie ec: 
x xor B[i] 


lsa (T) 
X 


0], Y[2], 
1], Y[3], 
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or V2 m= C2) 
sp MZ ae =li 


Informational 


|| BY [2 * r- 1] 
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5. The scryptROMix Algorithm 
The scryptROMix algorithm is the same as the ROMix algorithm 
described in [SCRYPT] but with scryptBlockMix used as the hash 


function H and the Integerify function explained inline. 


Algorithm scryptROMix 


Input: 

iai Block size parameter. 

B Input octet vector of length 128 * r octets. 

N CPU/Memory cost parameter, must be larger than 1, 

a power of 2, and less than 2^(128 * r / 8). 

Output: 

B’ Output octet vector of length 128 * r octets. 
Steps: 

1. KSB 


2. for i = 0 to N = 1 do 


V[i] = X 
X = scryptBlockMix (X) 
end for 


3. for i = 0 to N - 1 do 


j = Integerify (X) mod N 
where Integerify (B[0] ... B[2 * r - 1]) is defined 
as the result of interpreting B[2 * r - 1] as a 


little-endian integer. 
T = X xor V[j] 
X = scryptBlockMix (T) 
end for 
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The PBKDF2-HMAC-SHA-256 function used below denotes the PBKDF2 


algorithm [RFC2898] used with HMAC-SHA-256 


[RFC6234] as the 


must be larger than 1, 


a positive integer 
/ MFLen 


Pseudorandom Function (PRF). The HMAC-SHA-256 function generates 
32-octet outputs. 
Algorithm scrypt 
Input: 
P Passphrase, an octet string. 
S Salt, an octet string. 
N CPU/Memory cost parameter, 
a power of 2, and less than 2^(128 * r / 8). 
r Block size parameter. 
p Parallelization parameter, 
less than or equal to ((2%32-1) * hLen) 
where hLen is 32 and MFlen is 128 * r. 
dkLen Intended output length in octets of the derived 
key; a positive integer less than or equal to 
(2°32 - 1) * hLen where hLen is 32. 
Output: 
DK Derived key, of length dkLen octets. 
Steps: 


1. Initialize an array B consisting of p blocks of 128 * r octets 


each: 
B[0O] || B11 || || Bip - 1] = 
PBKDF2-HMAC-SHA256 (P, S, 1, p * 128 * r) 
2. for i = 0 to p- 1 do 
B[i] = scryptROMix (r, B[i], N) 
end for 
3. DK = PBKDF2-HMAC-SHA256 (P, B[0] || B[1] || || Bip - 1], 
1, dkLen) 
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7. 


ASN.1 Syntax 


This section defines ASN.1 syntax for the scrypt key derivation 
function (KDF). This is intended to operate on the same abstraction 
level as PKCS#5’s PBKDF2. The OID id-scrypt below can be used where 
id-PBKDF2 is used, with scrypt-params corresponding to PBKDF2-params. 
The intended application of these definitions includes PKCS #8 and 
other syntax for key management. 


The object identifier id-scrypt identifies the scrypt key derivation 
function. 


id-scrypt OBJECT IDENTIFIER ::= {1 3 6 1 4 1 11591 4 11} 


The parameters field associated with this OID in an 
AlgorithmIdentifier shall have type scrypt-—params: 


scrypt-params ::= SEQUENCE { 
salt OCTET STRING, 
costParameter INTEGER (1..MAX), 
blockSize INTEGER (1..MAX), 
parallelizationParameter INTEGER (1..MAX), 
keyLength INTEGER (1..MAX) OPTIONAL } 


The fields of type scrypt-params have the following meanings: 

- salt specifies the salt value. It shall be an octet string. 

- costParameter specifies the CPU/Memory cost parameter N. 

- blockSize specifies the block size parameter r. 

- parallelizationParameter specifies the parallelization parameter. 
- keyLength, an optional field, is the length in octets of the 
derived key. The maximum key length allowed depends on the 
implementation; it is expected that implementation profiles may 
further constrain the bounds. This field only provides convenience; 


the key length is not cryptographically protected. 


To be usable in PKCS#8 [RFC5208] and Asymmetric Key Packages 
[RFC5958], the following extension of the PBES2-KDFs type is needed: 


PBES2-KDFs ALGORITHM-IDENTIFIER ::= 
{ {scrypt-params IDENTIFIED BY id-scrypt}, ... } 
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For reference 


module here. 


-- scrypt ASN. 


scrypt-—0O {1 3 


DEFINITIONS 


id-scrypt OBJECT IDENTIFIER 


purposes, 


1 


6 


Module 


1 4 1 11591 4 10} 


BEGIN 


scrypt PBKDF 


August 2016 


the ASN.1 syntax is presented as an ASN.1 


scrypt-params 
salt OCTET STRING, 
costParameter INTEGER 


blockSize INTEGER 
parallelizationParameter INTEGER 
keyLength INTEGER 


} 


SEQUENCE { 


{4 E E a E S E N E 


(1..MAX), 
(1..MAX), 
(1..MAX), 
(1..MAX) OPTIONAL 


PBES2-KDFs ALGORITHM-IDENTIFIER 


{ 


END 


{scrypt-params IDENTIFIED BY id-scrypt}, 


8. Test Vectors for Salsa20/8 Core 


Below is a sequence of octets that illustrate input and output values 


for the Salsa20/8 Core. 
inserted for readability. 


INPUT: 

7e 87 9a 
ba ee 55 
ee 24 f3 
76 02 1d 


OUTPUT: 

a4 1f 85 
04 4b 21 
b4 39 31 
e4 24 cc 


21 
5b 
19 
29 


9c 
81 
68 
10 


4f 
8c 
df 
09 


66 
a2 
e3 
2c 


3e 
61 
9b 
CI 


08 
fd 
c9 
91 
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c9 
cl 
3d 
48 


cc 
33 
e6 
74 


86 
b5 
85 
29 


99 
7d 
be 
5c 


The octets are hex encoded and whitespace is 
The value corresponds to the first input 
and output pair generated by the first scrypt test vector below. 


re 
Od 
14 
ed 


3b 
fd 
fe 
24 


a9 
f8 
12 
eb 


81 
Tho 
6b 
ad 


40 
46 
le 
c6 


ca 
le 
c5 
67 


e6 
11 
4b 
8d 


cb 
63 
b7 
3d 


41 
6d 
5a 
b8 


02 
96 
ad 
GT 


71 
cd 
c5 
b8 


Oc 
68 
6d 
61 


Informational 


8f 
3b 
aa 
c2 


ef 
2f 
96 
8f 


26 
1d 
32 
5e 


05 
29 
ba 
81 
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Below is a sequence of octets that illustrate input and output values 
for scryptBlockMix. 
octets are hex encoded and whitespace is inserted for readability. 

The value corresponds to the first input and output pair generated by 


the first scrypt test vector below. 


INPUT 

B[O] = f7 
77 
89 
09 


B[1] = 89 
cd 
67 
TE 


OUTPUT 

B’ [0] = a4 
04 
b4 
e4 


B’ [1] = 20 
21 
Td 
5d 
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ce 
76 
£6 
4f 


49 
98 
d2 
4d 


LE 
4b 
39 
24 


ed 
07 
3b 
2a 


Ob 
16 
8f 
01 


91 
43 
TG 
le 


85 
21 
31 
cc 


e9 
Tc 
3d 
22 


65 
db 
48 
84 


44 
80 
51 
ad 


9c 
81 
68 
10 


75 
fe 
80 
58 


The test vector uses an r value of 1. 


3d 
bb 
11 
63 


72 
37 
ce 
6a 


66 
a2 
e3 
2c 


32 
Sf 
3b 
77 


2d 
27 
d1 
95 


13 
46 
4a 
52 


08 
fd 
c9 
91 


38 
8d 
60 
d5 


72 
a7 
e8 
74 


bb 
66 
d5 
3c 


cc 
33 
e6 
74 


81 
5E 
e4 
ed 


a4 
0e 
Tb 
f3 


22 
bb 
fe 
da 


99 
7d 
be 
5e 


a8 
e2 
ab 
f5 


10 
82 
cc 
9a 


6c 
8f 
d8 
77 


3b 
fd 
fe 
24 


05 
b1 
92 
84 


8c 
04 
3b 
e5 


25 
fc 
29 
Oe 


81 
Tho 
6b 
ad 


40 
a4 
09 
2c 


£5 
£3 
d7 
al 


b5 
b5 
c9 
67 


ca 
le 
e5 
67 


£6 
16 
96 
b9 


Informational 


ab 
ae 
40 
31 


4d 
bf 
Ob 
be 


cb 
63 
b7 
3d 


Ac 
8f 
e5 
fl 


e9 
2d 
Oa 
52 


a8 
40 
50 
ea 


02 
96 
ad 
eT 


16 
95 
9b 
4e 


T2 
Of 
9f 
17 


63 
c2 
5a 
af 


Oc 
68 
6d 
61 


2d 
36 
4d 
ef 


ff 
6f 
fd 
be 


70 
54 
57 
7e 


ef 
2f 
96 
8f 


cd 
78 
53 
e4 


dd 
ad 
29 
d7 


fb 
bO 
1b 
89 


05 
29 
ba 
81 


3c 
b7 
b6 
25 


The 
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Below is a sequence of octets that illustrate input and output values 


for scryptROMix. 


of Ll6, 


The test vector uses an r value of 1 and an N value 


The octets are hex encoded and whitespace is inserted for 


readability. 


pair generated by the first scrypt test vector below. 


INPUT: 
B = £7 
77 
89 
09 
89 
cd 
67 
7£ 


OUTPUT: 


B = 79 
2c 
d5 
ad 
ef 
ac 
ae 
4e 


ce 
76 
£6 
4f 
49 
98 
d2 
4d 


cc 
e3 
84 
b2 
11 
Ob 
12 
90 


Ob 
16 
8f 
O01 
91 
43 
ike 
le 


cl 
dd 
13 
f4 
42 
9c 
fd 
87 


The value corresponds to the first input and output 


65 
db 
48 
84 
44 
80 
51 
ad 


93 
4a 
67 
bb 
e6 
Fl 
44 
cb 


3d 
bb 
Ld. 
63 
72 
37 
ce 
6a 


62 
96 
3b 
a2 
5d 
be 
38 
33 


Percival & Josefsson 


2d 
27 
dl 
95 
13 
46 
4a 
52 


9d 
26 
99 
00 
5a 
2b 
£2 
39 


T2 
a7 
e8 
74 
bb 
66 
d5 
3¢ 


eb 
e3 
bO 
ee 
26 
ff 
03 
6a 


a4 
Oe 
7b 
f3 
22 
bb 
fe 
da 


ca 
55 
29 
9f 
6f 
ca 
ad 
68 


10 
82 
cc 
9a 
6c 
8f 
d8 
77 


04 
fa 
d6 
Oa 
dd 
30 
e4 
T3 
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8c 
04 
3b 
e5 
25 
fc 
29 
Oe 


7f 
fc 
65 
43 
ca 
Od 
el 
e8 


f5 
f3 
q7 
al 
b5 
b5 
c9 
67 


Ob 
61 
G3 
dl 
83 
01 
c4 
f9 


ab 
ae 
40 
31 
4d 
bf 
Ob 
be 


70 
98 
57 
9b 
2c 
ee 
7e 
d2 


e9 
2d 
Oa 
52 
a8 
40 
50 
ea 


60 
e6 
60 
57 
e5 
38 
c3 
53 


12 
Of 
9f 
17 
63 
c2 
5a 
af 


4b 
ea 
1f 
la 
9f 
76 
14 
9a 


ff 
6f 
fd 
be 
70 
54 
57 
7e 


f6 
2b 
b4 
9c 
aa 
19 
86 
4b 


dd 
ad 
29 
d7 
fb 
bo 
1b 
89 


b6 
46 
26 
Ti: 
TE 
c4 
1f 
8e 
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11. Test Vectors for PBKDF2 with HMAC-SHA-256 


Below is a sequence of octets that illustrate input and output values 
for PBKDF2-HMAC-SHA-256. The octets are hex encoded and whitespace 
is inserted for readability. The test vectors below can be used to 
verify the PBKDF2-HMAC-SHA-256 [RFC2898] function. The password and 
salt strings are passed as sequences of ASCII [RFC20] octets. 


PBKDF2-HMAC-SHA-256 (P="passwd", S="salt", 

c=1, dkLen=64) = 
55 ac 04 6e 56 e3 08 9f ec 16 91 c2 25 44 b6 05 
£9 41 85 21 6d de 04 65 e6 8b 9d 57 c2 0d ac be 
49 ca 9c cc f1 79 b6 45 99 16 64 b3 9d 77 ef 31 
7c 71 b8 45 b1 e3 Ob d5 09 11 20 41 d3 al 97 83 


PBKDF2-HMAC-SHA-256 (P="Password", ="Nacl", 
c=80000, dkLen=64) = 

4d de d8 f6 Ob 98 be 21 83 Oc ee Se f2 27 01 £9 

64 la 44 18 dO 4c 04 14 ae ff 08 87 6b 34 ab 56 

al d4 25 al 22 58 33 54 9a db 84 1b 51 c9 b3 17 

6a 27 2b de bb al dO 78 47 8f 62 b3 97 £3 3c 8d 
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12. Test Vectors for scrypt 


For reference purposes, 


The parameters to the scrypt function below are, 
password P (octet string), the salt S (octet string), 
cost parameter N, the block size parameter r, 
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we provide the following test vectors for 
scrypt, where the password and salt strings are passed as sequences 
of ASCII [RFC20] octets. 


parameter p, and the output size dkLen. 
and whitespace is inserted for readability. 


scrypt (p=" w s=" ny 


N=16, r=1, p= 


77 d6 57 62 38 65 7b 
f1 6b 48 44 e3 07 4a 
fc d0 06 9d ed 09 48 
e8 d3 e0 fb 2e Od 36 


scrypt (P="password", 
N=1024, r=8, 


1, 
20 
e8 
f8 
28 


p= 


dklen=64) = 

3b 19 ca 42 cl 8a 
df df fa 3f ed e2 
32 6a 75 3a Of c8 
cf 35 e2 Oc 38 dl 


="Nacl", 
16, dkLen=64) = 


fd ba be 1c 9d 34 72 00 78 56 e7 19 Od 01 
7o 6a d7 ch c8 23 78 30 e7 73 76 63 4b 37 
2e af 30 d9 2e 22 a3 88 6f f1 09 27 9d 98 
c7 27 af b9 4a 83 ee 6d 83 60 cb df a2 cc 


scrypt (P="pleaseletmein", 


N=16384, r=8, 
70 23 bd cb 3a fd 73 
fd a8 fb ba 90 4f 8e 
d5 43 29 55 61 3f Of 
e6 le 85 de Od 65 le 


scrypt (P="pleaseletmein", 
N=1048576, r= 


21 01 cb 9b 6a 51 la 
ec 56 8d 57 4a 2f fd 
8e 56 fd 8f 4b a5 dd 
37 30 40 49 e8 a9 52 


Percival & Josefsson 


P 
48 


3e 
cf 
40 


8, 

ae 
4d 
9f 
fb 


=1, dkLen=64) = 
46 ic 06 cd 81 fd 
a9 b5 43 f6 54 5d 
62 d4 97 05 24 2a 
df cf 01 7b 45 57 


p=1, dkLen=64) = 

ad db be 09 cf 70 
ab e5 ee 98 20 ad 
fa lc 6d 92 7c 40 
cb £4 5c 6f a7 7a 


Informational 


04 97 
14 42 
Le I7 
89 06 


e9 fe 
31 62 
30 da 
06 40 


S="SodiumChloride", 


38 eb 
al f2 
9a £9 
58 87 


S="SodiumChloride", 


£8 81 
aa 47 
f4 c3 
41 a4 


the 


the CPU/Memory 
the parallelization 
The output is hex encoded 
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13. Test Vectors for PKCS#8 


PKCS#8 [RFC5208] and Asymmetric Key Packages [RFC5958] encode 
encrypted private-keys. Using PBES2 with scrypt as the KDF, the 
following illustrates an example of a PKCS#8-encoded private-key. 
The password is "Rabbit" (without the quotes) with N=1048576, r=8, 
and p=1. The salt is "Mouse" and the encryption algorithm used is 
aes256-CBC. The derived key is: E2 77 EA 2C AC B2 3E DA-FC 03 9D 22 
9B 79 DC 13 EC ED B6 01 D9 9B 18 2A-9F ED BA 1E 2B FB 4F 58. 


MIHiMEOGCSQGS Ib3DQEFDTBAMB8GCSSGAQQB2kcECZASBAVNb3VzZQIDEAAAAgGETL 
AgEBMBO0GCWCGSAF lAwOBKgQQy YmguHMsOwzGMPoyObk/JgSBkJb47EWd5iAqJlyy 
t+nidftd6gZgOPaLQC1L7mEZc2KQay0VhjZm/ 7MbBUNbQOAXNM60GebXxVp6sHUAL 
iBGY/D1s7B1TsWeGObE0sS1MXEpuREuloZ jcsNVcNXWP1LdZtkSH6uwWZROPyG/Z 
+ZX£NodZtd/voKlvLOw5B30pGIFaLkbt LZQwMiGt142AS891Zg== 


14. Security Considerations 


This document specifies a cryptographic algorithm, and there is 
always a risk that someone will find a weakness in it. By following 
the cryptographic research area, you may learn of publications 
relevant to scrypt. 


ROMix has been proven sequential memory-hard under the random oracle 
model for the hash function. The security of scrypt relies on the 
assumption that BlockMix with Salsa20/8 Core does not exhibit any 
"shortcuts" that would allow it to be iterated more easily than a 
random oracle. For other claims about the security properties, see 
[SCRYPT]. 


Passwords and other sensitive data, such as intermediate values, may 
continue to be stored in memory, core dumps, swap areas, etc., fora 
long time after the implementation has processed them. This makes 
attacks on the implementation easier. Thus, implementation should 
consider storing sensitive data in protected memory areas. How to 
achieve this is system dependent. 


By nature and depending on parameters, running the scrypt algorithm 
may require large amounts of memory. Systems should protect against 
a denial-of-service attack resulting from attackers presenting 
unreasonably large parameters. 


Poor parameter choices can be harmful for security; for example, if 


you tune the parameters so that memory use is reduced to small 
amounts that will affect the properties of the algorithm. 
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